Skip to content

fix: avoid generating massive functions in get_mtkparameters_reconstructor#4539

Merged
AayushSabharwal merged 5 commits into
masterfrom
as/faster-iprobpmap
May 20, 2026
Merged

fix: avoid generating massive functions in get_mtkparameters_reconstructor#4539
AayushSabharwal merged 5 commits into
masterfrom
as/faster-iprobpmap

Conversation

@AayushSabharwal

Copy link
Copy Markdown
Member

This used to be the lion's share of the compile time in large models. The infrastructure added here might be useful in other places too, as a way to build simple one-off observed functions that mostly access u/p.

@KristofferC

Copy link
Copy Markdown
Contributor

Good to go?

@AayushSabharwal

Copy link
Copy Markdown
Member Author

No, pretty significant test failures. Some I can't easily reconcile.

@KristofferC

Copy link
Copy Markdown
Contributor

Which ones? It is hard to get an overview when a lot of tests typically fail on master as well. What is expected to pass / fail?

@AayushSabharwal

Copy link
Copy Markdown
Member Author

(1, ModelingToolkit/InterfaceII) should only fail with BVP-related stuff. QA should fail. lts and pre tend to be slightly stochastic depending on which runner we get, but should mirror the corresponding failures on master. Catalyst and SciMLSensitivity should pass. All the failures are related to the typeasserts in MTKParametersReconstructor. I'm working on finding a fix.

@KristofferC

Copy link
Copy Markdown
Contributor

Claude said something like:

The problem is in the MTKParametersReconstructor callable. CopyParamsByTemplate uses vcat internally, which can
  promote element types (e.g., if observed values return Float64 while tunables are Float32). The code then does a hard
  type assertion (::tunable_T) which fails instead of converting.

So perhaps do a conversion instad of a type assert, like:

diff --git a/lib/ModelingToolkitBase/src/systems/problem_utils.jl b/lib/ModelingToolkitBase/src/systems/problem_utils.jl
index 22c0bcb3..03ea9f2d 100644
--- a/lib/ModelingToolkitBase/src/systems/problem_utils.jl
+++ b/lib/ModelingToolkitBase/src/systems/problem_utils.jl
@@ -878,25 +878,25 @@ function (recon::MTKParametersReconstructor)(src, dst)
         tunablevals = recon.tunables_fn(src)
     else
         tunable_elT = promote_type(eltype(dst_ps.tunable), eltype(src_ps.tunable))
+        tunablevals = recon.tunables_fn(src)
         if ArrayInterface.ismutable(dst_ps.tunable)
             tunable_T = Base.promote_op(similar, typeof(dst_ps.tunable), Type{tunable_elT})
-            tunablevals = recon.tunables_fn(src)::tunable_T
         else
             tunable_T = StaticArraysCore.similar_type(typeof(dst_ps.tunable), tunable_elT)
-            tunablevals = recon.tunables_fn(src)::tunable_T
         end
+        tunablevals = convert(tunable_T, tunablevals)::tunable_T
     end
     if dst_ps.initials isa SVector{0}
         initialvals = recon.initials_fn(src)
     else
         initial_elT = promote_type(eltype(dst_ps.initials), eltype(src_ps.initials))
+        initialvals = recon.initials_fn(src)
         if ArrayInterface.ismutable(dst_ps.initials)
             initial_T = Base.promote_op(similar, typeof(dst_ps.initials), Type{initial_elT})
-            initialvals = recon.initials_fn(src)::initial_T
         else
             initial_T = StaticArraysCore.similar_type(typeof(dst_ps.initials), initial_elT)
-            initialvals = recon.initials_fn(src)::initial_T
         end
+        initialvals = convert(initial_T, initialvals)::initial_T
     end
 
     nonnumerics = recon.nonnumerics_fn(src)

maybe?

@AayushSabharwal

Copy link
Copy Markdown
Member Author

No, the vcat will have the correct type. The typeassert itself is wrong. I think I have something that works locally, just checking against every failing test.

@AayushSabharwal AayushSabharwal force-pushed the as/faster-iprobpmap branch 3 times, most recently from 3df9ec1 to bd2fb43 Compare May 19, 2026 06:32
@AayushSabharwal

Copy link
Copy Markdown
Member Author

SciMLSensitivity still doesn't like the typeasserts :(

@AayushSabharwal AayushSabharwal force-pushed the as/faster-iprobpmap branch 2 times, most recently from 8380ab4 to 1fa9629 Compare May 19, 2026 16:21
…ructor`

This used to be the lion's share of the compile time in large models.
The infrastructure added here might be useful in other places too.
Enables supporting ReverseDiff AD
@AayushSabharwal AayushSabharwal merged commit d284517 into master May 20, 2026
78 of 101 checks passed
@AayushSabharwal AayushSabharwal deleted the as/faster-iprobpmap branch May 20, 2026 10:50
@KristofferC

Copy link
Copy Markdown
Contributor

yay, happy to see this merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants